home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1234.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  2.1 KB  |  62 lines
  1.  
  2.  
  3. On ISMAP vs Figure Anchors.
  4. ==========================
  5.  
  6. I agree that bot the ISMAP technique of returning coordinates to a  
  7. server, and the FIGA (HMML) technique of overlaying anchors on
  8. pictures have uses.  I feel that in fact their application areas
  9. are quite separate.
  10.  
  11. It would be infuriating to have a ISMAP server which had some
  12. areas selectable and others not, where you got back an error
  13. message if you clicked in the wrong place.  But on the other hand,
  14. a good cyberspace web will have nodes on which you can click anywhere
  15. to change your point of view.
  16.  
  17. So let's specify both. Now for protocols.
  18.  
  19.     PLEASE KEEP OTHER INFO OUT OF LINKS
  20.  
  21. The ISMAP attribute has the problem that
  22. it includes information in the link which ought to be
  23. sent from the server when the map is retrieved.  I would
  24. suggest a methodname "SPACEJUMP" say in the Allowed: return
  25. field.  This allows the server to tag things as spacejumpable
  26. however you ahve got to them.  If for example you convert
  27. a URN ionto a URL and retrieve the document, then you get
  28. a spacejumpable version.  If you have a graphics machine.
  29. Some documents may become spacejumpable.  Having to put information
  30. like that in the links is bad because
  31.  
  32. 1.    It is duplication of information which implies
  33.     incorrect information.
  34.  
  35. 2.    It may change with time.
  36.  
  37. 3.    It may be a function of client and server
  38.     capabilities.
  39.     
  40. The same applied to the "type=immage/gif" which has been
  41. suggested and Pei mentioned.  PLEASE DON"T put type information
  42. into the link!  PLEASE use the full protcocol, using the libwww
  43. or otherwise.
  44.  
  45.     Scale coordinates please
  46.     
  47. I would point out too that we can forsee smart servers which will
  48. for example, as a function of the client, automatically generate or  
  49. select
  50. a 800*600 GIF to send instead of a 1200*1000 JPEG.  This will make
  51. transfers onto low-res and/or low-bandwidth clients much faster.
  52. It will be completely automatic. It means that ISMAP coordinates
  53. should be scaled to say 0 - 1.0 in the size of the picture,
  54. as pixels won't have much meaning.  Same applies of course anyway
  55. to postscript pictures which have no concept of pixel size.
  56.  
  57.  
  58. There's my 2c for today.
  59.  
  60.     Tim
  61.  
  62.